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(57) Techniques are disclosed to provide security for 
user output and input in which a first, host operating sys- 
tem is used along with a second, high assurance oper- 
ating system (nexus), where the first system provides at 
least some of the infrastructure for the second system. 
A trusted Ul engine has a trusted Input manager and a 
trusted output manager. The trusted input manager con- 
trots access to trusted input, distributing decrypted input 
to the host operating system where appropriate, or to 
the appropriate process running in the nexus. The trust- 
ed output manager manages output to the display, and 
allows trusted agents In the nexus to output data for dis- 
play without needing to be aware of output-device-de- 
pendent details. 
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Description 

FIELD OF THE INVENTION 

[0001] The present invention relates generally to the 5 
field of computer security. More particularly, the inven- 
tion relates to the use of plural execution environments 
(e.g., operating systems) on a single computing device, 
and provides techniques that allow for the integrity of 
input and output of data for a trusted agent in a higher- 
assurance execution environment from among the plu- 
ral execution environments. 

BACKGROUND OF THE INVENTION 

[0002] In modem computing, many tasl<s which can 
be performed on a computer require some level of se- 
curity. In order to provide a level of security, there are 
several options. One is to perform all secure applica- 
tions on a computer which is completely separate from 
any possibly insecure elements, or to use a virtual ma- 
chine monitor (VMM) to allow complete separation be- 
tween two execution environments (e.g. operating sys- 
tems) running on a single computer system. However, 
this may be impractical. There may be a need, for cost 
or convenience reasons, for a secure execution envi- 
ronment to share resources with applications with un- 
assured security, and those applications and those re- 
sources may be vulnerable to an attacker. Additionally, 
where a VMM is used, since a VMM requires full virtu- 
alization of the machine and all of its devices (thereby 
requiring that the VMM provide its own device driver for 
every possible device), a VMM is not well suited to an 
open architecture machine in which an almost limitless 
variety of devices can be added to the machine. 
[0003] One way to provide the ability to share resourc- 
es among two execution environments is to provide a 
computer system in which there is one "main" operating 
system that controls most processes and devices on a 
machine, and where a second operating system also ex- 
ists. This second operating system is a small, limited- 
purpose operating system alongside the main operating 
system which performs certain limited tasks. One way 
to make an operating system "small" or "limited-pur- 
pose" is to allow the small operating system to borrow 
certain infrastructure (e.g., the scheduling facility, the 
memory manager, the device drivers, etc.) from the 
"main" operating system. Since a VMM effectively iso- 
lates one operating system from another, this sharing of 
infrastructure is not practical using a VMM. 
[0004] Certain other techniques allow operating sys- 
tems to exist sIde-by-side on the same machine without 
the use of a VMM. One such technique is to have one 
operating system act as a "host" for the other operating 
system. (The operating system that the "host" is hosting 
is sometimes called a "guest.") In this case, the host op- 
erating system provides the guest with resources such 
as memory and processor time. Another such technique 



2 

is the use of an "exokemet." An exokemel manages cer- 
tain devices (e.g., the processor and the memory), and 
also manages certain types of interaction between the 
operating systems, although an exokemel - unlike a 
VMM - does not virtualize the entire machine. Even 
when an exokemel is used, it may be the case that one 
operating system (e.g., the "main" operating system) 
provides much of the infrastructure for the other, in 
which case the main operating system can still be re- 
ferred to as the "host," and the smaller operating system 
as the "guest." Both the hosting model and the exokemel 
model allow useful types of interaction between operat- 
ing systems that support sharing of infrastructure. 
[0005] Thus, these techniques can be used to provide 
a computer system with at least two execution environ- 
ments. One of these may be a "high-assurance" oper- 
ating system, referred to herein as a "nexus." A high- 
assurance operating system is one that provides a cer- 
tain level of assurance as to its behavior. For example, 
a nexus might be employed to work with secret informa- 
tion (e.g., cryptographic keys, etc.) that should not be 
divulged, by providing a curtained memory that is guar- 
anteed not to leak information to the world outside of the 
nexus, and by permitting only certain certified applica- 
tions to execute under the nexus and to access the cur- 
tained memory. 

[0006] In a computer system with two execution envi- 
ronments, one of which is a nexus, it may be desirable 
for the nexus to be the guest operating system, and a 
second operating system, not subject to the same level 
of assurance as to behavior, to be the host operating 
system. This allows the nexus to be as small as possi- 
ble. A small nexus allows a higher level of confidence 
in the assurance provided by the nexus. 
[0007] However, the high-assurance nature of the 
nexus requires high-assurance for input and output to 
processes running on the nexus, so that no process or 
other entity from the host operating system can read or 
alter the data entered by the user, or the data being dis- 
played or output to the user. But allowing the host oper- 
ating system to handle input and output and relay infor- 
mation to the nexus for its processes would imperil the 
high-assurance nature of the nexus. Additionally, input 
may be from a trusted user input device which encrypts 
the input, and it may be necessary to decrypt the data 
using a secret held within the nexus which should not 
be divulged to the host. 

[0008] Input/output (1/0) functions such as rendering 
and detecting and handling user events on graphical us- 
er interface elements which are being displayed to the 
user are often provided by a common resource for all 
processes. However, providing this functionality in a 
host operating system requires that data to be rendered 
be passed to the host for rendering. This provides a pos- 
sible avenue of attack on the high-assurance nature of 
the process passing the data out for rendering, as the 
data being sent for rendering may be read or altered by 
a host-side entity which should not have access to the 
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data. The same vulnerability is present in the notification 
that a user event has occurred. 
[0009] In view of the foregoing there is a need for a 
system that overcomes the drawbacks of the prior art. 

SUMMARY OF THE INVENTION 

[0010] The security of a secured execution environ- 
ment on a system with a secured execution environment 
and a second execution environment is maintained us- 
ing a trusted Ul engine. The trusted Ul engine arbitrates 
user input to the secured execution environment and 
output from processes in the secured execution envi- 
ronment to a display or output device. 
[0011] In one embodiment, one component of the 
trusted Ul engine is a trusted input manager. When en- 
crypted input arrives from a trusted input device, the 
trusted input manager decrypts the input. A determina- 
tion is then made if the input should remain in the se- 
cured execution environment or sent to the second ex- 
ecution environment. Encrypted input is passed to the 
second execution environment only after a determina- 
tion in the secured user environment. 
[0012] One component of the trusted Ul engine is a 
trusted output manager. In order to provide security for 
the output, the trusted output manager functions as the 
contact point for all entities in the secured execution en- 
vironment the output device. 

[0013] Other features of the invention are described 
below. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0014] The foregoing summary, as well as the follow- 
ing detailed description of preferred embodiments, is 
better understood when read in conjunction with the ap- 
pended drawings. For the purpose of illustrating the in- 
vention, there is shown in the drawings exemplary con- 
structions of the invention: however, the invention is not 
limited to the specific methods and instrumentalities dis- 
closed. In the drawings: 

[001 5] FIG. 1 is a block diagram of an exemplary com- 
puting environment in which aspects of the invention 
may be implemented; 

[0016] FIG. 2 is a block diagram of two exemplary ex- 
ecution environments that maintain some Interaction 
with each other and some separation from each other; 
[0017] FIG. 3 is a block diagram a computer system 
with two execution environments showing input accord- 
ing to one embodiment of the invention; 
[0018] FIG. 4 is a flow diagram of a method for pro- 
viding secure input from entities in a secured execution 
environment according to one emt)odiment of the inven- 
tion; 

[0019] FIG. 5 is a block diagram a computer system 
with two execution environments showing output ac- 
cording to one embodiment of the invention; and 
[0020] FIG. 6 is a flow diagram of a method for pro- 



viding secure output from entities in a secured execution 
environment according to one embodiment of the Inven- 
tion. 

5 DETAILED DESCRIPTION OF THE INVENTION 

Overview 

[0021] When two execution environments, such as 
10 operating systems, run side-by-side on a single ma- 
chine, it must be determined how user input and output 
should be accessed by the operating systems. Moreo- 
ver, one of the operating systems may need to be pro- 
tected from accessing user input or output for or from 
15 the second operating system or an entity running on the 
second operating system. The present invention pro- 
vides techniques that allow user input and output direct- 
ed at or coming from a high assurance entity on a nexus 
to be protected from possible discovery by host operat- 
ic Ing system entities. 

Exemplary Computing Arrangement 

[0022] FIG. 1 shows an exemplary computing envi- 

25 ronment in which aspects of the invention may be im- 
plemented. The computing system environment 100 is 
only one example of a suitable computing environment 
and is not intended to suggest any limitation as to the 
scope of use or functionality of the invention. Neither 

30 should the computing environment 100 be interpreted 
as having any dependency or requirement relating to 
any one or combination of components illustrated in the 
exemplary operating environment 100. 
[0023] The invention is operational with numerous 

35 other general purpose or special purpose computing 
system environments or configurations. Examples of 
well known computing systems, environments, and/or 
configurations that may be suitable for use with the in- 
vention include, but are not limited to, personal comput- 

40 ers, server computers, hand-held or laptop devices, 
multiprocessor systems, microprocessor-based sys- 
tems, set top boxes, programmable consumer electron- 
ics, network PCs, minicomputers, mainframe comput- 
ers, embedded systems, distributed computing environ- 

45 ments that include any of the above systems or devices, 
and the like. 

[0024] The invention may be described in the general 
context of computer-executable Instructions, such as 
program modules, being executed by a computer. Gen- 

50 erally, program modules include routines, programs, ob- 
jects, components, data structures, etc. that perform 
particular tasks or implement particular abstract data 
types. The invention may also be practiced in distributed 
computing environments where tasks are performed by 

55 remote processing devices that are linked through a 
communications network or other data transmission 
medium. In a distributed computing environment, pro- 
gram modules and other data may be located in both 
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local and remote computer storage media including 
memory storage devices. 

[0025] With reference to FIG. 1 . an exemplary system 
for implementing the invention includes a general pur- 
pose computing device in the form of a computer 110. 
Components of computer 110 may include, but are not 
limited to, a processing unit 120, a system memory 130. 
and a system bus 1 21 that couples various system com* 
ponents including the system memory to the processing 
unit 120. The processing unit 120 may represent multi- 
ple logical processing units such as those supported on 
a multi-threaded processor. The system bus 121 may 
be any of several types of bus structures including a 
memory bus or memory controller, a peripheral bus, and 
a local bus using any of a variety of bus architectures. 
By way of example, and not limitation, such architec- 
tures include Industry Standard Architecture (ISA) bus, 
Micro Channel Architecture (MCA) bus, Enhanced ISA 
(EISA) bus, Video Electronics Standards Association 
(VESA) local bus, and Peripheral Component Intercon- 
nect (PCI) bus (also known as Mezzanine bus). The sys- 
tem bus 121 may also be implemented as a point-to- 
point connection, switching fabric, or the like, among the 
communicating devices. 

[0026] Computer 110 typically includes a variety of 
computer readable media. Computer readable media 
can be any available media that can be accessed by 
computer 110 and includes both volatile and nonvolatile 
media, removable and non-removable media. By way 
of example, and not limitation, computer readable media 
may comprise computer storage media and communi- 
cation media. Computer storage media includes both 
volatile and nonvolatile, removable and non-removable 
media implemented in any method or technology for 
storage of information such as computer readable in- 
structions, data structures, program modules or other 
data. Computer storage media includes, but is not lim- 
ited to, RAM, ROM, EEPROM, flash memory or other 
memory technology, CDROM, digital versatile disks 
(DVD) or other optical disk storage, magnetic cassettes, 
magnetic tape, magnetic disk storage or other magnetic 
storage devices, or any other medium which can be 
used to store the desired information and which can ac- 
cessed by computer 1 1 0. Communication media typical- 
ly embodies computer readable instructions, data struc- 
tures, program modules or other data in a modulated 
data signal such as a carrier wave or other transport 
mechanism and includes any information delivery me- 
dia. The term "modulated data signal" means a signal 
that has one or more of its characteristics set or changed 
In such a manner as to encode information in the signal. 
By way of example, and not limitation, communication 
media includes wired media such as a wired network or 
direct-wired connection, and wireless media such as 
acoustic, RF, infrared and other wireless media. Com- 
binations of any of the above should also be included 
within the scope of computer readable media. 
[0027] The system memory 130 includes computer 



storage media in the form of volatile and/or nonvolatile 
memory such as read only memory (ROM) 1 31 and ran- 
dom access memory (RAM) 132. A basic input/output 
system 133 (BIOS), containing the basic routines that 

5 help to transfer information between elements within 
computer 110, such as during start-up, is typically stored 
in ROM 131. RAM 132 typically contains data and/or 
program modules that are immediately accessible to 
and/or presently being operated on by processing unit 

10 120. By way of example, and not limitation, FIG. 1 illus- 
trates operating system 134, application programs 135, 
other program modules 136, and program data 137. 
[0028] The computer 110 may also include other re- 
movable/non-removable, volatile/nonvolatile computer 

15 storage media. By way of example only, FIG. 1 illus- 
trates a hard disk drive 140 that reads from or writes to 
non-removable, nonvolatile magnetic media, a magnet- 
ic disk drive 151 that reads from or writes to a remova- 
ble, nonvolatile magnetic disk 152, and an optical disk 

20 drive 1 55 that reads from or writes to a removable, non- 
volatile optical disk 156, such as a CD ROM or other 
optical media. Other removable/non-removable, vola- 
tile/nonvolatile computer storage media that can be 
used In the exemplary operating environment include, 

25 but are not limited to, magnetic tape cassettes, flash 
memory cards, digital versatile disks, digital video tape, 
solid state RAM, solid state ROM, and the like. The hard 
disk drive 141 is typically connected to the system bus 
121 through a non-removable memory interface such 

30 as interface 140, and magnetic disk drive 151 and opti- 
cal disk drive 155 are typically connected to the system 
bus 121 by a removable memory interface, such as in- 
terface 150. 

[0029] The drives and their associated computer stor- 

35 age media discussed above and Illustrated in FIG. 1 , 
provide storage of computer readable instructions, data 
structures, program modules and other data for the 
computer 110. In FIG. 1, for example, hard disk drive 
141 is illustrated as storing operating system 144, ap- 

40 plication programs 145, other program modules 146. 
and program data 1 47. Note that these components can 
either be the same as or different from operating system 
134, application programs 135, other program modules 
136, and program data 137. Operating system 144, ap- 

45 plication programs 145, other program modules 146. 
and program data 147 are given different numbers here 
to illustrate that, at a minimum, they are different copies. 
A user may enter commands and information into the 
computer 20 through input devices such as a keyboard 

50 162 and pointing device 161, commonly referred to as 
a mouse, trackball or touch pad. Other input devices (not 
shown) may include a microphone, joystick, game pad, 
satellite dish, scanner, or the like. These and other input 
devices are often connected to the processing unit 120 

55 through a user input interface 1 60 that is coupled to the 
system bus, but may be connected by other interface 
and bus structures, such as a parallel port, game port 
or a universal serial bus (USB). A monitor 1 91 or other 
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type of display device is also connected to the system 
bus 121 via an interface, such as a video interface 190. 
In addition to the monitor, computers may also include 
other peripheral output devices such as speakers 1 97 
and printer 196, which may be connected through an 5 
output peripheral interface 190. 
[0030] The computer 1 1 0 may operate in a networked 
environment using logical connections to one or more 
remote computers, such as a remote computer 1 80. The 
remote computer 180 may be a personal computer, a 
sender, a router, a network PC, a peer device or other 
common network node, and typically includes many or 
all of the elements described above relative to the com- 
puter 110, although only a memory storage device 181 
has been illustrated in FIG. 1. The logical connections 
depicted in FIG. 1 include a local area network (LAN) 
171 and a wide area network (WAN) 173, but may also 
include other networks. Such networking environments 
are commonplace in offices, enterprise-wide computer 
networks, intranets and the Intemet. 
[0031] When used in a LAN networking environment, 
the computer 110 is connected to the LAN 171 through 
a network interface or adapter 170. When used in a 
WAN networking environment, the computer 110 typi- 
cally includes a modem 172 or other means for estab- 
lishing communications over the WAN 173, such as the 
Internet. The modem 172, which may be internal or ex- 
ternal, may be connected to the system bus 121 via the 
user input interface 160, or other appropriate mecha- 
nism. In a networked environment, program modules 
depicted relative to the computer 11 0, or portions there- 
of, may be stored in the remote memory storage device. 
By way of example, and not limitation, FIG. 1 illustrates 
remote application programs 185 as residing on mem- 
ory device 181. It will be appreciated that the network 
connections shown are exemplary and other means of 
establishing a communications link between the com- 
puters may be used. 

Plural Computing Environments on a Single Machine 

[0032] As previously described, it is known in the art 
that two operating systems can execute side-by-side on 
a single computing device. One problem that the 
present invention addresses Is the issue of can be used 
to address is how to provided some level of separation 
between two operating system, while still providing for 
some level of interaction between the two operating sys- 
tems. 

[0033] FIG. 2 shows a system in which two operating 
systems 1 34(1 ) and 1 34(2) execute on a single compu- 
ter 110. Some type of logical separation 202 exists be- 
tween operating systems 134(1) and 134(2), such that 
a certain amount of interaction 204 is permitted between 
operating systems 1 34(1 ) and 1 34(2), while still allowing 
at least one of the operating systems to be protected 
against events that originate in the other operating sys- 
tem. In the example of FIG. 2. operating system 134(1) 



is a host operating system, and operating system 134 
(2) is a guest operating system, such as a "nexus" as 
described above. As previously noted, when operating 
system 1 34(2) is a nexus, it is desirable to construct sep- 
aration 202 such that operating system 1 34(2) can in- 
teract with operating system 134(1) in order to borrow 
operating system 134(1 )'s infrastructure, while still al- 
lowing operating system 134(2) to protect itself from ac- 
tions (either malicious or innocent) that arise at operat- 
ing system 134(1) and might cause operating system 
134(2) to behave in a manner contrary to its behavioral 
specifications. (It will be understood, however, that the 
invention is not limited to the case where operating sys- 
tem 134(2) is a nexus.) 

[0034] The separation 202 between operating sys- 
tems 134(1) and 134(2) may, optionally, be enforced 
with the aid of a security monitor. A security monitor is 
a component external to both operating systems 134(1) 
and 134(2), which provides some security services that 
may be used to protect operating system 134(2) from 
operating system 134(1 ). For example, a security mon- 
itor may control access to certain hardware, may man- 
age the use of memory (to give operating system 134 
(2) exclusive use of some portions of memory), or may 
facilitate the communication of data from operating sys- 
tem 134(1) to operating system 134(2) in a secure way. 
It should be noted that the use of a security monitor rep- 
resents one model of how operating system 1 34(2) can 
be protected from operating system 134(1), although 
the use of a security monitor is not required. As another 
example, operating system 134(2) could include all of 
the functionality necessary to protect itself from operat- 
ing system 134(1). 

[0035] It should be noted that FIG. 2 shows operating 
system 134(1) as a "host" and operating system 134(2) 
as a "guest." In general, this characterization refers to 
the fact that, in these examples, operating system 134 
(1) provides certain operating system infrastructure that 
is used by both operating systems 1 34(1 ) and 1 34(2) (e. 
g., device drivers, scheduling, etc.), and operating sys- 
tem 134(2) is a "guest" in the sense that it preferably 
lacks this infrastructure but rather uses the infrastruc- 
ture of operating system 134(1). However, it should be 
noted that the parameters of what makes an operating 
system a "host" or a "guest" are flexible. Moreover, it 
should be noted that traditional concepts of "host" and 
"guest" operating systems presume that the host needs 
to protect itself from actions of the guest. In the example 
of FIGS. 2, however, guest operating system 134(2) is 
presumed to be a high-assurance operating system that 
needs to protect itself from host operating system 134 
(1 ). In the examples that follow, we shall generally refer 
to operating system 134(1) as the "host" and operating 
system 134(2) as the "guest" or "nexus" for the purpose 
of distinguishing between them. It should be appreciat- 
ed that the techniques described herein can be applied 
to the interaction of any two or more operating systems 
running on the same machine (or even on the same set 
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of connected machines). 

Secure Input and Output to a Trusted Agent 

[0036] In order to provide secure input and output to s 
the nexus and to processes running on the nexus ("trust- 
ed agents" or "nexus agents") a trusted user interface 
(Ul) engine module is provided on the nexus side. The 
trusted Ul engine provides a common resource for se- 
cure input and output functionality for trusted agents. 
[0037] To provide high-assurance for user input, the 
trusted Ul engine accepts trusted user input. The secu- 
rity of the user Input may be secured by encrypting the 
input. In other embodiments, the security of the user in- 
put is verified by other verification means such as a dig- 
ital signature, or ensured by other means such as se- 
cure trusted hardware. The trusted Ul engine includes 
a trusted input manager which then determines the 
proper destination for the user input. In some cases, the 
user Input should be used on the host side. In such cas- 
es, the user input will be placed in an input stack on the 
host side for the host operating system. However, in 
some cases, the user Input Is high-assurance, and Is 
directed by the trusted Input manager to the proper des- 
tination, for example, to a nexus agent. 
[0038] To provide high-assurance for output, the trust- 
ed Ui engine accepts trusted output from agents and 
other processes to a trusted output manager. The trust- 
ed output manager receives this trusted output and han- 
dles the display of trusted output in a device-dependent 
way, based on how the computer system 110 provides 
trusted output for the nexus. In one embodiment, en- 
crypted memory is used to describe dedicated display 
areas. This encrypted memory is passed to the host 
side. Because the memory is encrypted, the host side 
can not decrypt the memory or create bogus content for 
the dedicated display areas. In another embodiment, 
curtained memory is used, along with an embedded vid- 
eo adapter for that memory. The trusted output manager 
provides nexus agents with the ability to output display 
data in a device-independent way. While the output is 
generally described as being visual output, it should be 
appreciated that the use of a trusted output manager 
and the techniques described herein can be applied to 
any type of trusted output (such as audio, printer, or oth- 
er outputs), and that the invention is not limited to visual 
output. 

Secure Input Functionality of the Trusted Ul Engine 

[0039] With respect to input, according to one embod- 
iment of the invention, the trusted Ul engine controls ac- 
cess to trusted input. When a user interacts with pro- 
grams on a computer system containing a high-assur- 
ance operating system, the user does so by means of 
a user input device, such as mouse 161 or keyboard 
162 (from FIG. 1). In one embodiment, some or all of 
the user input devices may support encryption. Such en- 



crypted devices allow the input device and the nexus to 
establish a secure connection and can thus prevent a 
hardware attack. Other input devices may exist which 
are not encrypted, however, input from unencrypted us- 
er input devices is only accepted for the host system, 
and not for the nexus or any entitles running on the nex- 
us. 

[0040] Thus, In order to provide input which is secure, 
the trusted Ul engine, and not a host-side entity, will con- 
trol the initial flow of at least one stream of user input. 
FIG. 3 is a block diagram a computer system with two 
execution environments showing input according to one 
embodiment of the invention. As shown in FIG. 3, a trust- 
ed Input device 300 sends encrypted user Input data to 
computer system 110. The encrypted data arrives in the 
input stack 305 in the host-side operating system 134 
(1). Because it is encrypted, it can not be used by the 
host-side operating system 134(1). Thus, it is secured 
from possible attack on the host side. The encrypted da- 
ta is passed to the nexus 134(2). 
[0041] In FIG. 3, both the host side (to the right of log- 
ical separation 202) and the nexus side (to the left of 
logical separation 202) are divided further Into user level 
310 and kernel level 320. These correspond to distinc- 
tions between user level and kernel level execution in 
operating systems. When the nexus 134(2) receives the 
encrypted user input data, it is passed to the input trust- 
ed service provider (TSP) 325, where the encrypted us- 
er input data Is decrypted. In some embodiments, the 
secure input device 300 must establish a communica- 
tions channel, for example using a shared secret and 
verification, in order to communicate with computer sys- 
tem 110. Where a communications channel is required 
with the secure input device 300, the TSP 325 estab- 
lishes and manages the communication channel with 
the secure input device. In another embodiment, the us- 
er input data is verifiable, and the TSP 325 provides ver- 
ification for the user input data, for example by verifying 
a digital signature of the user input data. 
[0042] The decrypted user input data is then passed 
to the trusted user interface (Ul) engine (TUE) 330. spe- 
cifically to the trusted input manager 340. A detemriina- 
tion is made by the trusted input manager whether the 
user input should be directed to the host side, or whether 
it is intended for the nexus or a nexus agent, such as 
nexus agent 375. If the input is destined for use on the 
host side, it is restored to the input stack 305 for use on 
the host side, as shown by arrow C 390. Thus, the de- 
crypted user input data only reaches the host side upon 
a determination in the nexus side. 
[0043] In one embodiment, the computer system 1 1 0 
presents the user with a windowing interface environ- 
ment, populated with graphical user interface elements 
such as windows, dialog boxes, and icons. Graphical 
user interface elements can be associated with or 
"owned by" processes on the host side or with process- 
es on the nexus side. When using a windowing system, 
a user's display can be populated with windows, areas 
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on the screen which display infonrtation from an appli- 
cation. An application may have one or more windows. 
One window of all the windows displayed may have fo- 
cus. The focus window may be indicated by a different 
border around the window, for example. s 
[0044] in traditional windowing systems, when a win- 
dow has focus, it is generally the object of the user's 
Input. Therefore, if a user types information using a key- 
board, in many cases, the keystroke data will be sent by 
the operating system to the application which owns the 
window which has focus. Some keystrokes and other 
input actions may not be sent to the application which 
owns the window with focus. For example, in some win- 
dowing systems there is a keystroke command which 
minimizes all windows. Such a command will be han- 
dled by the windowing system, and not sent to the ap- 
plication owning the window with focus. The application 
owning the focused-on window may receive notification 
of the minimization of the window; however, the user 
keystrokes are intended for the windowing system, not 
the application owning the window having focus, and will 
not be sent to that application. 
[0045] In one embodiment, the trusted Ul engine in- 
cludes a trusted window manager 345. This trusted win- 
dow manager 345 manages windows and window be- 
havior for the nexus side. The trusted window manager 
345 acts in conjunction with the trusted input manager 
340 to detemnine where user input data should be 
passed. In one embodiment, this decision is based, at 
least in part, on whether the window or graphical user 
element which has focus is owned by a process In the 
nexus or a process in the host. 
[0046] The trusted window manager may maintain 
window decoration such as borders and respond to user 
input for window functions such as maximization, mini- 
mization and resizing of windows. In one embodiment, 
the trusted window manager also performs some inter- 
pretation of the user input data. For example, raw user 
input data describing that a mouse button has been de- 
pressed or that a keystroke has been made, in one em- 
bodiment, will be interpreted to a more usable form for 
a nexus agent, such as nexus agent 375, analogous to 
the function generally performed by host window man- 
ager 346. 

[0047] If the input Is for a nexus agent such as nexus 
agent 375. the data will be passed from the trusted input 
manager to the correct destination nexus-mode proc- 
ess. This is illustrated by arrow A 370, which shows user 
input data being sent to nexus agent 375. In one em- 
bodiment, other data may be passed to TOM 350 or to 
other entities on the nexus side. The display of nexus- 
side graphical user interface elements is handled by the 
trusted output manager (TOM) 350 and so mouse move- 
ments over nexus-side user interface elements are 
passed to TOM 350, as shown by arrow B 380. 
[0048] FIG. 4 is a flow diagram of a method for pro- 
viding secure Input from entities in a secured execution 
environment (a nexus) according to one embodiment of 



the invention. In step 400, user input is accepted from 
a user input device. In step 41 0. it is determined whether 
the user input is Intended for nexus, for example if the 
user input is for an agent running in the nexus. And in 
step 420, if the user input is not intended for the nexus, 
the user input is transferred to the host. 

Secure Output Functionality of the Trusted Ul Engine 

[0049] The secure output functionality of the trusted 
output engine is provided by the trusted Ul engine 330 
via trusted output manager 350. FIG. 5 is a block dia- 
gram a computer system with two execution environ- 
ments showing output according to one embodiment of 
the invention. As shown in FIG. 5, arrow D 500, when 
nexus agent 375 has output for output device 520, that 
output is relayed to the trusted Ul engine 330. In order 
to provide security for the output, the trusted output 
manager 340 functions as the contact point for the nex- 
us side with the output trusted service provider (TSP) 
530, and thereby with the output device 520. as seen by 
arrow E 51 0. 

[0050] As described above, there are several ways in 
which output device 520 can be secured. In one embod- 
iment, encryption is used. If output device 520 receives 
output data in the encrypted form which decrypts cor- 
rectly, it will prioritize that output data, allowing it to over- 
write non-nexus output data on the display. In another 
embodiment, curtained memory is used. The trusted 
output manager 350 interacts with the output TSP 530 
to maintain security of output device 520. 
[0051] Independent of the type of security present on 
the output, the trusted output manager 350 manages all 
interactions between the nexus side and the output de- 
vice 520. including handling any output information from 
the trusted window manager 345. in a computer system 
110 incorporating a trusted window manager 345. The 
output information from windows owned by nexus 
agents such as nexus agent 375 is handled by the trust- 
ed output manager 350. In addition, If any other nexus 
graphical user interface elements are present, the dis- 
play of these elements are handled by the trusted output 
manager. For example, where a mouse moves over 
such a nexus window, allowing the host side to control 
the mouse may be difficult without causing security 
problems. Therefore, the display of the mouse cursor 
when the mouse is over a nexus window may be han- 
dled on the nexus side. The output information of all nex- 
us windows and other nexus graphical user Interface el- 
ements are composited by the trusted output manager 
for display. Additionally, any interaction with host win- 
dow manager 346 Is handled by trusted Ul engine 330. 

Secure Output Fu nctionality of the Trusted Ul Engine 

[0052] Generally, dialog framework services may be 
provided for processes. These sen/lces accept a file de- 
scribing the desired graphical user interface elements 
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to display. For example, the file may be an XML file with 
information describing a dialog box to present to the us- 
er, including a specified question, response options, and 
a language to use in presenting the dialog box. The di- 
alog framework service contains the information which 
renders the correct dialog box. However, relying on a 
dialog framework service on the host side would intro- 
duce security problems. Therefore a trusted rendering 
Interface, in one embodiment, is provided in the trusted 
Ul engine 330. This trusted rendering interface provides 
a complete dialog framework service for nexus agents 
such as nexus agent 375. As part of the trusted Ul en- 
gine 330, the trusted rendering interface receives the 
information specifying how the graphical user interface 
element for display, and the trusted rendering interface 
renders the requested graphical user interface and 
manages it, alerting the nexus agent 375 when user 
events occur on active graphical user interface ele- 
ments within it. In this way, the trusted Ul engine 330 
provides some of the localization services that nexus 
agent 375 needs for graphical user interface without re- 
quiring the use of localization services in the host side. 
For example, the trusted Ul engine 330 can provide mul- 
ti-lingual text services. 

[0053] In one embodiment, a direct rendering inter- 
face is provided in the trusted Ul engine 330. This direct 
rendering interface may be provided in addition to the 
trusted rendering Interface, or it may be present even 
where the trusted rendering interface is not. The direct 
rendering interface provides the bare-bones mecha- 
nism for a nexus agent such as nexus agent 375 which 
wishes to perform its own rendering. The nexus agent 
375 will compute its own screen bitmaps, rather than 
relying on the trusted Ul engine 330 to render them from 
specifications. The trusted Ul engine sends notification 
of user input actions through the trusted Input manager 
340. 

[0054] FIG. 6 is a flow diagram of a method for pro- 
viding secure output from entities in a secured execution 
environment according to one embodiment of the inven- 
tion. In step 600, output is accepted from a specific 
source entity in a secured execution environment, such 
as the nexus. In step 610, the output is transferred se- 
curely to an output device. 

Conclusion 

[0055] It is noted that the foregoing examples have 
been provided merely for the purpose of explanation 
and are in no way to be construed as limiting of the 
present invention. While the invention has been de- 
scribed with reference to various embodiments, it is un- 
derstood that the words which have been used herein 
are words of description and illustration, rather than 
words of limitations. Further, although the invention has 
been described herein with reference to particular 
means, materials and embodiments, the invention is not 
intended to be limited to the particulars disclosed herein; 



rather, the invention extends to alt functionally equiva- 
lent structures, methods and uses, such as are within 
the scope of the appended claims. Those skilled in the 
art, having the benefit of the teachings of this specifica- 
5 tion, may effect numerous modifications thereto and 
changes may be made without departing from the scope 
and spirit of the invention in its aspects. 



10 Claims 

1 . A method for providing a secure user interface to a 
secured execution environment on a system com- 
prising said secured execution environment and an 
15 second execution environment, comprising: 

accepting user input from a user input device; 
determining whether said user input is intended 
for said secured execution environment; 
20 if said user input is not intended for said se- 

cured execution environment, transferring said 
user input to said second execution environ- 
ment. 

25 2. The method of claim 1 , where said step of accepting 
user input from a user input device comprises de- 
crypting said user input. 

3. The method of claim 1 , where said step of accepting 
30 user input from a user input device comprises es- 
tablishing a secure communications channel with 
said user input. 

4. The method of claim 1 . where said step of accepting 
35 user Input from a user input device comprises ver- 
ifying said user Input. 

5. The method of claim 1 , further comprising: 

40 If said user Input is intended for said secured 

execution environment, determining a specific 
destination entity in said secured execution en- 
vironment for said user input; and 
transferring said user input to said specific des- 

45 tination entity. 

6. The method of claim 5, where said step of determin- 
ing a specific destination entity in said secured ex- 
ecution environment further comprises: 

50 

providing window management functionality for 
managing at least one graphical user interface 
element owned by said specific destination en- 
tity; and 

55 determining that said user input relates to said 

graphical user interface element. 

7. The method of claim 5, where said step of transfer- 
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ring said user input to said specific destination entity 
comprises: 

interpreting said user input. 

8. The method of claim 1 . further comprising: 

accepting output from a specific source entity 
in said secured execution environment; and 
securely transferring said output to an output 
device. 

9. The method of claim 8, where said step of securely 
transferring said output to said output device com* 

prises: 

encrypting said output data. 

10. The method of claim 8, where said step of securely 
transferring said output to said output device com- 
prises: 

transferring said output to a curtained memory. 

11. A method for providing a secure user interface to a 
secured execution environment on a system com- 
prising said secured execution environment and an 
second execution environment, comprising: 

accepting output from a specific source entity 

in said secured execution environment; and 
securely transferring said output to an output 
device. 

1 2. The method of claim 1 1 , where said step of securely 
transferring said output to said output device com- 
prises: 

encrypting said output data. 

13. The method of claim 1 1 , where said step of securely 
transferring said output to said output device com- 
prises: 

transferring said output to a curtained memory. 

14. A computer-readable medium containing computer 
executable instructions to providing a secure user 
interface to a secured execution environment on a 
system comprising said secured execution environ- 
ment and an second execution environment the 
computer-executable instructions to perform acts 
comprising: 

accepting user input from a user input device; 
determining whether said user input is intended 
for said secured execution environment; 
if said user input is not intended for said se- 



cured execution environment, transferring said 
user input to said second execution environ- 
ment. 

5 15. The computer-readable medium of claim 14, where 
said accepting user input from a user input device 
comprises decrypting said user input. 

16. The computer-readable medium of claim 1 4, where 
10 said accepting user input from a user input device 

comprises establishing a secure communications 
channel with said user input. 

17. The computer-readable medium of claim 14, where 
15 said accepting user input from a user input device 

comprises verifying said user input. 

18. Thecomputer-readablemediumof claim 14, where- 
in the computer-executable instructions are adapt- 

20 ed to perform acts further comprising: 

if said user input is intended for said secured 
execution environment, determining a specific 
destination entity in said secured execution en- 
25 vironment for said user input; and 

transferring said user input to said specific des- 
tination entity. 

19. The computer-readable medium of claim 1 8, where 
30 said detemiining a specific destination entity in said 

secured execution environment further comprises: 

providing window management functionality for 
managing at least one graphical user interface 
35 element owned by said specific destination en- 

tity; and 

determining that said user input relates to said 
graphical user interface element. 

40 20. The computer-readable medium of claim 1 8, virhere 
said transferring said user input to said specific des- 
tination entity comprises: 

interpreting said user input. 

45 

21. Thecomputer-readablemediumof claim 14. where- 
in the computer-executable instructions are adapt- 
ed to perfomn acts further comprising: 

50 accepting output from a specific source entity 

in said secured execution environment; and 
securely transferring said output to an output 
device. 

55 22. The computer-readable medium of claim 21 , where 
said securely transferring said output to said output 
device comprises: 
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encrypting said output data. 

23. The computer-readable medium of claim 21 , where 
said securely transferring said output to said output 
device comprises: 

transferring said output to a curtained memory. 

24. A computer-readable medium containing computer 
executable instructions to providing a secure user 
interface to a secured execution environment on a 
system comprising said secured execution environ- 
ment and an second execution environment, the 
computer-executable Instructions to perfomi acts 
comprising: 

accepting output from a specific source entity 
In said secured execution environment; and 
securely transferring said output to an output 
device. 

25. The computer-readable medium of claim 24, where 
said step of securely transferring said output to said 
output device comprises: 

encrypting said output data. 

26. The computer-readable medium of claim 24, where 
said step of securely transferring said output to said 
output device comprises: 

transferring said output to a curtained memory. 

27. A trusted user interface engine for providing a se- 
cure user interface to a secured execution environ- 
ment on a system comprising said secured execu- 
tion environment and an second execution environ- 
ment, comprising: 

an input trusted service provider accepting user 
input from a user input device, operably con- 
nected to said user device; 
a trusted input manager for determining wheth- 
er said user input is intended for said secured 
execution environment and, if said user input is 
not intended for said secured execution envi- 
ronment, transferring said user input to said 
second execution environment. 

28. The trusted user interface engine of claim 27, where 
said input trusted service provider decrypts said us- 
er Input. 

29. The trusted user interface engine of claim 27, where 
said input trusted service provider establishes a se- 
cure communications channel with said user input. 

30. The trusted user interface engine of claim 27, where 



said input trusted sen^ice provider verifies said user 
input. 

31 . The trusted user interface engine of claim 27, where 
5 said trusted input manager, if said user input is in- 
tended for said secured execution environment, de- 
termines a specific destination entity in said se- 
cured execution environment for said user input; 
and where said trusted input manager further trans- 

10 fers said user input to said specific destination en- 
tity. 

32. The trusted user interface engine of claim 31, fur- 
ther comprising: 

15 

a trusted window manager that provides win- 
dow management functionality for managing at 
least one graphical user interface element 
owned by said specific destination entity; and 
20 where said trusted input manager determines 

that said user input relates to said graphical us- 
er interface element 

33. The trusted user interface engine of claim 31 , where 
25 said trusted Input manager interprets said user in- 
put for said specific destination entity. 

34. The trusted user interface engine of claim 27. fur- 
ther comprising: 

30 

a trusted output manager that accepts output 
from a specific source entity in said secured ex- 
ecution environment; and that securely trans- 
fers said output to an output device. 

35 

35. The trusted user interface engine of claim 34, where 
said trusted output manager encrypts said output 
data. 

40 36. The trusted user interface engine of claim 34, where 
said trusted output manager transfers said output 
to a curtained memory. 

37. A trusted user interface engine for providing a se- 
45 cure user interface to a secured execution environ- 
ment on a system comprising said secured execu- 
tion environment and an second execution environ- 
ment, comprising: 

50 a trusted output manager that accepts output 

from a specific source entity in said secured ex- 
ecution environment; and that securely trans- 
fers said output to an output device. 

55 38. The trusted user interface engine of claim 37, where 
said trusted output manager encrypts said output 
data. 
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39. The trusted user interface engine of claim 37, where 
said trusted output manager transfers said output 
to a curtained memory. 

40. The trusted user interface engine of claim 37, where s 
said trusted output manager comprises: 

a trusted rendering interface providing render- 
ing said output from said specific source entity; 
and where said secure transfer is a transfer of 
said rendered output. 
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